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Header compression for general packet radio service tunneling protocol (GTP) 



(57) A UMTS (Universal Mobile Telecommunica- 
tions System) core network supports a compression 
framework that provides for header compression of 
General Packet Radio Service Tunneling Protocol 
(GTP)-Encapsulated Packets. In particular, the GTP/ 



UDP(User Datagram Protocol)/IP(lnternet Protocol) 
header is compressed. In addition, the UMTS core net- 
work also supports RTP(Real Time Protocol)/UDP/IP 
header compression independent of the GTP/UDP/IP 
header compression. 
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Description 

FIELD OF THE INVENTION 

5 [0001] This invention relates generally to communications and, more particularly, to packet communications systems. 
BACKGROUND OF THE INVENTION 

[0002] As wireless systems continue to evolve, communications between a mobile switching center (MSC) and its 
10 base stations are moving to an internet Protocol (IP) based transport mechanism. (As used herein, the term wireless 
systems refers to e.g., CDMA (code division multiple access), GSM (Global System for Mobile Communications), the 
proposed UMTS (Universal Mobile Telecommunications System), etc.) Given the nature of wireless communications, 
e.g., real-time voice, any IP-based transport needs to utilize a protocol that accommodates real-time applications. 
[0003] One such protocol is the Real Time Protocol (RTP) (e.g., see H. Schulzrinne, R. Frederick, V. Jacobson, "Hi H: 
15 A Transport Protocol for Real-Time Applications* RFC 1 889). RTP is attractive since ft is an available Internet Engi- 
neering Task Force (IETF) protocol for handling real-time streams. RTP traffic is encapsulated in UDP (user datagram 
protocol), and IP packets. 

[0004] Unfortunately, the use of RIP/UDP/IP generates a large overhead when voice-over-IP applications are run 
over wireless networks since the voice payload is usually small (e.g. 1 0 to 20 bytes) while the RTPAJDP/IP header is 
20 40 bytes. 

SUMMARY OF THE INVENTION 

[0005] Besides the large overhead associated with RTPAJDP/IP headers, this situation is further aggravated by the 
25 use of General Packet Radio Service Tunneling Protocol (GTP)-Encapsulated Packets. In this case, the GTP/UDP/IP 
overhead is about 980% with a voice payioad of 10 bytes. Therefore, and in accordance with the invention, the GTP/ 
UDP/IP header Is compressed for transmission. 

[0006] In an embodiment of the invention, a UMTS core network supports a compression framework that provides 
for compression of a GTPAJDP/IP header (referred to herein as "GTP header compression" or a "compressed GTP 
so header"). In addition, the UMTS core network also supports RTP/UDP/IP header compression (referred to herein as 
"RTP header compression" or a "compressed RTP header") independent of the GTP header compression. As a result, 
the UMTS core network is able to more efficiently transport small multimedia RTP packets. 

BRIEF DESCRIPTION OF THE DRAWING 

35 

[0007] 

FIG. 1 shows a prior art uncompressed GTP encapsulated RTP packet; 

FIG. 2 shows a UMTS network embodying the principles of the invention; 
40 FIGs. 3 and 4 show illustrative protocol stacks for use in a mobile station; 

FIG. 5 shows illustrative compressor/decompressor locations in the UMTS network of FIG. 2; 

FIGs. 6-10 show illustrative message flows 

FIGs. 11-13 show prior art IP, UDP and RTP header formats; 

FIG. 14 shows an illustrative format for a compressed RTP header; 
45 FIG. 15 shows an illustrative format for a compressed GTP header; and 

FIG. 1 6 shows an illustrative high-level block diagram of a packet server for use in performing GTP header com- 
pression in accordance with the principles of the invention.. 

DETAILED DESCRIPTION 

so 

[0008] An illustrative format of an uncompressed GTP encapsulated RTP packet 1 0, as known in the art (release 97 
version), is shown in FIG. 1. The GTP/UDP/1P header 11 comprises an IP/UDP header 12 and a GTP header 13. The 
GTP/UDP/IP header 1 1 sits on top of GTP payload 1 4 as known in the art. With a voice payload illustratively equal to 
10 bytes (e.g., payload 15 of FIG. 1), this results in an overhead of about 980% as a result of the GTP/UDP/IP header 
55 11. Therefore, and in accordance with the invention, the GTP/UDP/IP header is compressed for transmission. It can 
be observed from FIG. 1 that GTP payload 14 also transports an IP header and a UDP header. As known in the art, 
IP/UDP header 12 comprises origination and destination information with respect to the tunnel, while the IP header 
and UDP header of GTP payload 14 comprises origination and destination information with respect to the communi- 
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cations endpoints. (It should be noted that the TID value Is based upon the release 97 version as defined in Global 
System for Mobile Communications (GSM) 04.08 document. Digital *» llul " te 'f™ m ^ 
mobile radio Interface layer 3 - specification. The TID value Includes 8 bytes: 1 2 btts MCC. 8 b » ™^ MSIN 
and 4 bits NSAPI. The MCC, MNC, MSIN and NSAPI are parts of the IMSI defined in the GSM 04.08 document.) 
5 [0009] An illustrative UMTS network 200 modified In accordance with the principles of the invention is shown In FIG 
2. Other than the inventive concept, the elements shown in FIG. 2 are well known and will not be described mdetari. 
For example. UMTS network 200 comprises a radio access network (RAN), a core network (CN), a t backbone network 
and an Illustrative endpolnt represented by IP End Host 240. The backbone network comprises the Internet and the 
P^ics^ 

w controller 215. (Although UMTS uses the term "node B," this is also referred to as a base stat.on.) The CN corses 
a serving GPRS support node (SGSN) 220. gateway GPRS support node (GGSN) 225 and element 230^hich com- 
prises a gatekeeper (GK) (a component in ITU H.323) and an IP/PSTN gateway (GW) (for trans labon between H 323 
and the PSTN). Although shown as single block elements, the eiements of U ^ S " e ^ 0 * 200,n t^rt P D Z^n" 
control processors, memory, and appropriate interface cards (not shown) For the W™™*™**^™^ 

is i|,ustrat£e end-to-end connection is between MS 205 and IP End Host 240 (which are als 0 / efe ^^^^ 

The term -packet server" as used herein refers to any packet processor, illustrations of which are the above-mentioned 

[OoToT^n f 8^in2\vith the invention, UMTS network 200 supports a compression framework that Prides for 
GTP header compression. In addition, UMTS network 200 also supports RTP header compressor, 

20 GTP header compression. (As used herein the temns "GTP header compression" or "compressed GTP 'header" refer 
to compression of aGTPAJDP/IP header. Similarly, the terms "RTP headercompression "^^^^^ 
refer to compression of an RTP/UDP/IP header.) Since GTP headercompression is independent from RTP header 
compression the GTP peers can be different from the RTP peers (but this Is not required) This ateo provides some 
design flexibility since some multimedia traffic may not use RTP but purely UD encapsulation^ M , a ' 

25 network 200 Is able to more efficiently transport small multimedia packets. The descnption of the inventive concept 
continues below. 

Overview of Header Compression ' 

so [0011] It should be understood that, in accordance with the invention, RTP header compression and GTP header 
compLs o can be negotiated independently between peers (described further below). 
reptWessior^decoVsslon techniques are weli-knownand^ 

a compressor/decompressor is a software module stored in a memory (not shown), e.g., of MS 205, and ex^uted by 
aSed^ogram-controlled microprocessor (not shown), e.g., of MS 205. The software modu e uses eomwnbond 
35 programming techniques, which, as such, will also not be described herein, to store shared '"formation^ (de scrtoed 
belfwTandfLatfonransmissioncom P ressed.orred 

[uuSrwSpect to the mobiie station, e.g. MS 205 of FIG. 2, two illustrate protocol stacks oqrfe^ 
pressor/decomprLor are shown in FIGs. 3 and 4. In the protocol stack of FIG. 3, the RTP f^^^S 
40 Is located between the IP layer and the RLC/MAC (radio link control/media access control) link layer. (For simplicity, 
SSystca^ 

to located between the application layer and the RLC/MAC link layer. (Again, the physical layer is not shown.) (Although 
aon?o?^ 

Sform of FTTP header compression In which an RTP header is simply stripped off In its entirety (an RTP header is 

Pressor are located in the UMTS network. An illustrate view of the location of the 
and the GTP compressor/decompressor in UMTS network 200 is shown in RQ 5. n RTP 
decompressor (C/D) Is located In MS 205 and IP end host 240 (I.e., MS 205 and IP end host 240 are RTP P^ers) » 
* STG^mpSr/decompressor (C/D) is located in RNC 215 and GGSN 225 (i.e., RNC 215 and GGSN 225 are 

foO^rSTP is a point-to-point protocol. As such, for RTP header compression pee*, it should be noted that thfe 
assumes that a linklayer identifier\lD) is mapped to each RTP session identifier. One ''' ust '^ v ® ^^.^^ ^^pQ 
comprises the IP destination address and the IP destination port number (these are of * e end P™*>; J e ^SRC 
55 Wentifler (e a see FIG 13) and the UDP destination port (e.g., see FIG. 12). If ATM (asynchronous transfer mode) 
^SS^^S^li ^trative .ink layer ID is the associated VP./VC. (Virtual Path ..dentmer/V.rtual Connect.cn 
Identifier) The mapping of the link layer ID and the RTP session occurs within each RTP peer. 
[001 5] | It Should ateo be noted that an RTP compressor/decompressor can alternately be put m the rad.o access 



3 




EP1 122 925 A1 

network, e.g., in RNC 215, or even in the core network, e.g., at SGSN 220. 

[0016] Within the core network, it is preferable (though not required) to put the GTP compressor/decompressor in 
GGSN 225. If the GTP compressor/decompressor is located in SGSN 220, handovers ( also known in the art as "hand- 
offs") due to SRNS (Serving Radio Network Subsystem) relocation may still have to be accounted for. (As known in 
s UMTS, an SRNS includes not only a particular RAN but also supporting elements, e.g., a data base (not shown).) 
However, with the GTP compressor/decompressor located at GGSN 225, no context transfer is required even for the 
case of SRNS relocation. 

[0017] Turning now to FIGs. 6-10, illustrative message flows for using GTP header compression and RTP header 
compression in UMTS network 200 are shown. Other than the inventive concept, the description that follows utilizes 

10 well-known UMTS message flows, which are not described herein, in FIGs. 6 - 1 0 it is assumed that the GTP header 
peers are RNC 215 and GGSN 225, while the RTP header peers are MS 205 and IP End Host 240. 
[0018] FIG. 6 illustrates how a mobile station, e.g., MS 205 of FIGs. 2 and 5, negotiates GTP header compression/ 
decompression. After the "Attach Procedures" are performed between MS 205 and RNC 215 (as known in the art), 
MS 205 transmits to SGSN 220 an "Activate PDP (packet data protocol) context" request message modified, in ac- 

15 cordance with the invention, to include a GTP header compression request represented by a predefined identifier 
designated as "GTP_Comp." In response, SGSN 220 sends a "Create PDP context" request message (modified to 
include the "GTP_Comp" identifier) to GGSN 225 to signify a request for GTP header compression. GGSN 225 re- 
sponds with a "Create PDP context" response message as an acknowledgment (modified to include the "GTP_Comp" 
identifier). Upon receipt of the "Create PDP context" response message, SGSN 220 sends an "Activate PDP context" 

20 response message (modified to include the "GTP_Comp" identifier) to MS 205. 

[001 9] As noted above, in order to establish a GTP header compression context, either a GTP_Compressed flag (e. 
g., a predefined bit pattern) or a GTP Header Compression Context Information Element (IE) is added to the existing 
message set. This GTP Header Compression_Context IE will comprise the GTP full header information, if this element 
is present, one need not send a full GTP header to establish the GTP header context Otherwise, one may need to 

25 send one or more packets with full GTP header to establish GTP header context (It should be noted that for the case 
where the GTP compressor/decompressor is located at an SGSN, and an SRNS relocation occurs resulting in a change 
of SGSN, the new SGSN can send a GTP context enquiry message to the old SGSN and the oid SGSN can reply with 
the appropriate GTP context response message so that the new SGSN can now be the new compressor/decompressor 
point for GTP header compression.) 

30 [0020] Turning now to FIG. 7, illustrative packet flows are shown. For GTP header compression, at least one packet 
with a full GTP header is sent to establish the GTP compressed header context (FIG. 7, (A)) between the GTP peers 
(here, represented by RNC 215 and GGSN 225). As noted, packets are communicated using GTP between GGSN 
225 and RNC 215 (i.e., GTP terminates at GGSN 225 and RNC 215). Once the GTP header compression is negotiated, 
each GTP peer, e.g., GGSN 225 formats data packets in accordance with GTP and then compresses the GTP header 

35 before transmitting the packets (described below) to its GTP peer, here RNC 21 5, which uncompresses the GTP header 
and recovers the payload (which may or may not include RTP) for transmission to MS 205. Similarly, in the other 
direction, RNC 215 compresses the GTP header for transmission to GGSN 225, which uncompresses the GTP header 
and recovers the payload. Packets are communicated between GGSN 225 and I P End Host 240 with a link layer header 
as known in the art. Subsequent to GTP header compression negotiation, RTP header compression may optionally 

40 be negotiated between MS 205 and IP End Host 240 (FIG. 7, (B)) in a similar fashion as that shown for the GTP header 
compression negotiation of FIG. 6. 

[0021] Illustrative RTP header compression context message exchanges are shown in FIG. 8. (Again, modification 
of existing signaling messages are assumed. As such predefined bit values are added to existing message sets to 
identify the additional message requirements, e.g., that this is an "RTP context set up" message.) initially, two RTP 

45 peers exchange signaling messages to set up the RTP header compression context An "RTP context set up" request 
message is sent from one RTP peer, e.g., MS 205, to the other RTP peer, e.g., IP End Host 240. An "RTP context Set 
up" response message completes the handshake. Whenever there is a change in the RTP context, the appropriate 
context update code is used in the first byte of the compressed RTP header (described below) to indicate the additional 
changed (or delta) information carried within the RTP compressed header. Thus, an "RTP context update" request 

50 message is an implicit message in the RTP compressed header. However, an "RTP context update" response message 
is optional. (It should be noted that the RTP header compression between the two RTP peers (here represented by 
MS 205 and IP End Host 240) can exchange out-of-band signaling messages to turn on the RTP header compression. 
Again, since the GTP header compression and the RTP header compression are independent of each other, it is not 
necessary for RTP header compression to be negotiated (in which case, the packets comprise a compressed GTP 

55 header and an uncompressed RTP payload.) Similarly, it is not necessary for GTP header compression to be negotiated 
notwithstanding the use of RTP header compression. 

[0022] Returning to FIG. 7, once the RTP header compression context is set up, subsequent packets are sent using 
GTP header compression and RTP header compression (FIG. 7, (C)) (as noted, assuming both GTP header compres- 
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sion and FTP header compression are turned on). In the event RTP context re-synchron.zat.on 
RTP peer can send a "RTP context repair" message to the sending RTP peer. This is illustrated in FIG. 9 (D), where 
the receiving RTP peer is represented by IP End Host 240 and the sending RTP peer is represented by MS 205. The 
sending RTP peer then sends one or more RTP packets with full header (FIG. 9 (E)) followed by compressed RTP 

MS 8 Simter^when GTP packets are lost, the receiving GTP peer can send a "GTP context repair" message* 
the sending GTP peer. This is illustrated in FIG. 10. (G). where the receiving GTP peer is represented by GGSN 225 
and the sending GTP peer is represented by RNC 215. The sending GTP peer then sends one or more packets with 
a full GTP header (FIG. 10. (H)) followed by packets with compressed GTP headers(FIG. 10. (I)). (It should be observed 

10 that in this example. RTP header compression synchronization was not lost.) h . al<a , Mm ™» 
[0024] The above-described context repair mechanism for either GTP header compression or RTP header compres- 
sion is performed whenever there are missing packets. It should be noted that one can set a predefined time interval 
threshold beyond which an explicit context repair message is sent to the sender to re-synchronize. . 
[0025] Whenever either GTP peer wishes to tear down the GTP context, they can send a GTP <™texttear down 

is message (not shown). Similarly, the RTP peers can tear down the RTP context via the transmission of an RTP context 
tear down message (not shown). 
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RTP Header Compression 



20 [0026] Although not directly applicable to a UMTS environment, there are existing proposals to reduce the 40-byte 
R^DpTheaderto4- S 7yt^ 

Speed Serial Links," IETF RFC2508; and L. Jonsson and M. Degermark and H. Hannu and K. Svanbn* Robust 
Checksum-based Header Compression". IETF Internet draft. Oct 1 999). As such, while FIGs 11-13 show pnor art 
IP RTP and UDP header formats for reference purposes, the details of such are not described herein 
[0027] Generally, with respect to an IP header (assuming use of IPv4, the IP version in use today . 
ength, packet ID (identification) and header checksum fields will normally change. However, the total length is redun- 
dant since the length is also provided by the link layer. The packet ID usually increment by 

each packet. If it was assumed that there was nolPpacketfragmentation.thls also would not need to be communicated. 
However, in order to maintain lossless compression, changes In the packet ID may be transmrtted. 
[0028] With respect to a UDP header, the length field is redundant since the IP total length field and the length are 
Indicated by the link layer. The UDP check-sum field will be a constant zero if the source elects not to generate UDJ 
checksums. Otherwise. I have observed that the UDP checksum must be communicated Intact in order to preserve 

SoMr'mrrreTp'StTan RTP header, the SSRC (synchronization source) identifier is constant In a given contgt 
since that is part of what Identifies the particular context For most packets, only the sequence number and £h ^times- 
temp will change from packet to packet. If packets are not lost or misordered upstream from censor the 
sequence number will increment by one for each packet. For audio packets of constant duration 
increment by the numberof sample periods conveyed In each packet. For video, the tmestamp will change. >r .the first 
padcet of eachframe.butthensteyconstentforany additional packete in theframe^^ 

one packet, but the video frames are generated at a constant rate, then again the change in Umesta^^m f mrne 
toframeisconstant It should be noted that In each of these cases me second-order differ^ 
and timestamp fields is zero, so the next packet header can be constructed from the previous packet header by adding 
SnTt-orderdifferencesforthesefleldsthatare stored in 

header. When the second-order difference is not zero, the magnitude of the change is usudly much smaller ^than the 
flTnumber of bits in the field, so the size can be reduced by encoding the new first-order difference and transm.tt.ng 

it rather than the absolute value. „.„,„„ if » wore treated 

[0030] The M bit is set on the first packet of an audio talkspurt and the last packet of a v.deo frame. A *« r ^ted 
as a constant field such that each change required sending the full RTP header, this J 
header compression significantly. Therefore, as described further below, an RTP compressed header will carry the M 

50 SSTR- Packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list an. I CC count 
Z also change. However, the CSRC list will typically remain constant during a telkspurt or longer, so it need be sent 

^TAn" SSe format for a compressed RTP header is shown in FIG. 14 for 
55 compesslonpmtocol.Asnotedabove.itisassum^ 

a collection of shared information (e.g., stored in a memory (not shown) m a consistent state between the compressor 
and decompressor). The compressed RTP header comprises the following fields: 
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a Context Update Code (one byte); 
- an M field (one bit) for the RTP M bit; 
a time clicks field (seven bits); 
a UDP checksum field (two bytes); 
5 - an IP packet ID (two bytes); 

a CSRC list (two bytes); and 

an FTTP header extension (two bytes). 

[0033] The value of the Context Update Code field indicates what Information is included in the RTP compressed 
10 header as shown in FIG. 14. The minimal length for the RTP compressed header is 2 bytes. The RTP timestamps are 
replaced by a timeclick number (1 byte), if the UDP checksum, IPv4 Packet ID, CSRC list and RTP header extension 
need to be included, the compressed RTP header will be longer as shown in FIG. 14. However, most of the time, the 
compressed RTP header will only be 2 bytes (the context update code byte and the M + timeclick byte). 
[0034] With respect to the shared information stored in each RTP peer, there is a separate session context for each 
15 IP/UDP/RTP packet stream, as defined by a particular combination of the IP source and destination addresses, UDP 
source and destination ports, and the RTP SSRC field (described earlier). The number of maintained session contexts 
may be negotiated between the compressor and decompressor. Once can map each RTP context to a GTP TID (GTP 
tunnel ID) (the maximum number that can be negotiated is 65536). Each RTP header compression context has its own 
separate sequence number space so that a single packet loss need only invalidate one context 
20 [0035] The shared information in each RTP header compression context comprises the following items: 

the full IP, UDP and RTP headers, possibly including a CSRC list, for the last packet sent by the compressor or 
reconstructed by the decompressor; and 

the first-order difference for the IPv4 !D field, initialized to 1 whenever an uncompressed IP header for this context 
25 is received and updated each time a delta IPv4 ID field is received in a compressed packet. 

[0036] As mentioned above, and shown in FIG. 14, there is a timeclicks field in the compressed RTP header which 
replaces the RTP timestamps field of an RTP header (e.g., see FIG. 13). As such, a mechanism is required o compute, 
or recover, the timestamp value and sequence number in an RTP receiving peer from the timeclicks field value. As 
30 such, the following definitions are made: 

sd: sample duration (in ms); 
TS^ timestamp number for the previous packet; 
TS,,^ timestamp number for this packet; 
35 WTom wall clock reading for the previous packet (a wall clock is simply a network reference clock); 

WT^ wall clock reading for this packet; 

TNakf timeclick number of previous packet in compressed header, 
TN^ timeclick number of this packet in compressed header; 
SN^ RTTP sequence number of previous packet; 
40 $ N ne»r sequence number of this packet; 

T: time period represented using n bits (a cycle period), in units of sample duration, T=2P samples (T = 2P(sd) 

milliseconds (ms)); and 

M: the value of M bit in compressed header. 

45 [0037] The following equations are used to compute, or recover, the timestamp value and sequence number in an 
RTP receiving peer from the timeclicks field value: 



TS m = TSoid + /; ifM= Oand <5U « 1\ and (1) 

- TSoid + (Scycic * T + Suck) otherwise; (2) 



SN new = SN ctd + 5 tfc*> if 6 tlck ! = 1 . and 5 tick < ™ and M ! = 1 1 < 3 > 

where 
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S**= ( T+ ™nm>- TN M )mo<fr; (where modT Is a modulo T operation); W 



<?cycle = # cycle " A if &uck < <Xick, and &e* - <W ^ T/2\ (?) 

- + A if 5„ick < and - &<* T/2; and (8) 
= ^;«, otherwise. < 9 > 



(5) 

(6) 



[0038] During a talkspurt. the tlmeclicks field value will increase by one sample. During a silent period, the timeclicks 
field will Increase by the idle period (expressed In terms of the number of samples). ,^„.. m K»r 

• [0039] For the tinLtamp 1W the major problem to serve is what to do for the case when the ™tt"^""£; 
wraps Ground. During a silent period, if there is no packet sent by the compressor, the t™*^ 1 ™***^™* 
mustbe detected (in terms of how many clock cycles has passed). Illustratively, a wall clock as known in the art « 
rdtoo^rSneLprob.emtasshownabove.e.g.. I^and ^) ™ sse P ar ^'^ k f^ 

(or receiving RTP peer) is used to count the cycles. This wall-cluck 'runs at a coarse granularity, e.g. it only Increases 
25 by 1 for every 774 period where T is the time period of a cycle represented using 7 bits. 

100401 With respect to the RTP sequence number field, if sequencing is required, a compressed header wrth se- 

can be sent to request a full RTP header if necessary. If the timeclick value exceeds T/4. and there are lost Packets 
ZSHSSSi number cant be updated appropriateiy until the RTP receiver gets a packet with sequence number 

5S5r*n "lustration of how this update algorithm works to provide timestamp and sequence number re^veo £ 
show,! beiow. it is assumed that 1 8 packets are transmitted from, e.g., MS 205 wrth ""-^ 

1 to 18 At the RTP receiver, e.g., IP End Host 240, only packet 1 8 is received (i.e., packets 7 to 17 are lost). 

0042] Tnttefiit example its Is assumed that the wall clock value is 3 (meaning 3(T/4» when ' P^^,f£«£ 

* numbere fe "Lived and that T S<M = 110. When packet 18 is received, the wall clockvalue is 6™ e ^ Kte ™ " e 
at So P Ss6 and 1 8 are *0 and 75. respectiveiy. Using the equations above, the following cateulafonsresuft. 



TS oW =110; 
5ft* = (128 + 75 - 110) motfT = 93; 
5*** = ( 6 (T"/ 4 ) - 3fT/4))modT= 3(7/4) = 96; 
S'cyck, = l - 3(T/4)yn = 0; 



8cycle = 0; 



55 



and 

TS„= 110 + 93 = 203 
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[0043] In the following second example, it is assumed that TS^^ 38 and that the wall clock value for packet 6 is 5, 
while the wall clock value for packet 1 8 is 9. The timeclicks value at receipt of packets 6 and 1 8 are 38 and 32, respec- 
tively. 

TS oW = 38; 
8^ = (128 + 32 - 38) modT= 122; 

10 

*wtt* = < 9 CT /4 > ■ 5Cr/4))/mx/T= 0; 



15 



5 W=l " 5(T/4)yrj = 1; 



5 cycte = °: 

20 and 

75,^=38+122=160. 

25 [0044] In the following third example, it is assumed that TS^ ~ 57 and that the wall clock value for packet 6 is 6, 
while the wall clock value for packet 1 8 is 9. The timeclicks value at receipt of packets 6 and 1 8 are 57 and 28, respec- 
tively. 
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TS oJtf = 57; 
s «c* = (128 + 28 - B7)modT= 29; 
$wthtr ( 9 074) - 6(T/4))/7)OGT = 3( 7/4) = 96; 
S'oete=L &(T/4)-6(T/4))/rj=0; 
^cycte = 1 1 

and 

TS naw = 57+122 = 21 4. 

GTP Header Compression 

[0045] FIG. 1 5 shows an illustrative format for a compressed GTP header. The compressed GTP header comprises 
a version field (Vers, 3 bits), a payload type field (PT, 1 bit), an extension bit field (E, 1 bit), a sequence number field 
(S, 1 bit), a tunnel identifier (TID) present field (T, 1 bit), an SNDCP present field (N, 1 bit), a message type field (Msg 
Type, 1 byte), a two byte length field, a two to four byte tunnel identifier (TID) field, a two byte sequence number field, 
a four bit extension code filed, a four bit extension length field, and an extension content field. 
[0046] With respect to the TID field, the most significant bit is used to indicate the size of the TID field. If the value 
of the most significant bit is 0, then the TID field size is 2-bytes. If the value of this bit is one, then the TID field size is 
four bytes. In addition, the TID field is present only if the value of the T bit field is SET, i.e., equal to a binary one. The 
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E-bit f ield is used to indicate if an extension header exists. Each extension header compnses a 4 bit f «ens.on header 
type (Ext. Type) field, a 4 bit extension header length (Ext. length) field, and an extension content (Ext. C^^fleU 
ftne size of which is indicated by the value of the extension header length field). The value of the extension header 
ength field is expressed in terms of multiples of 2 bytes. For example, if a UDP checksum needs to be presen an 
5 appropriate extension header type is defined for this and the extension header length is 1 (meaning the s.ze of the 
extension content field is 2 bytes since a UDP checksum Is 2 bytes long). 

[0047] Since the extension header type fieid is four bits wide. 16 types of extens,ons can be . ^ned^Sm ce the 
extension header length field is four bits wide, the extension contentfield has a maximum size bytes 0^. IBtwo 
byte multiples). It should be noted that if more extension types need to be allocated, the size of these f.elds can be 

" headercompresslon context (i.e.. stored - :eacf , GTF • peer) co mpHses 

the following items (these items are initialized based on the values received in the mrtial full GTP header). 

. the full IP and UDP headers (also, should a UDP checksum be required, the receiving GTP peer simply re-calcu- 
15 lates it based upon the received UDP data); 

- the two byte flow label and the LLC Frame number; and 

- the TID value. 

[0049] As noted above, the GTP header compression format shown in FIG. 15 supports either two or four byte 
20 UonalTIDvalues.(Asnotedabov^^ 

inthefutureto comprise fewer bytes (hence the option of having eitherTID values of twoor ° urb ^ mt t h h e ~J"P r ^ 
GTP header). The TID field in the GTP header compression format of FIG. 15 is optionally used (va the value of the 

T bit) for updating TID information. . . 

EDoSq TumingbrieflytoFIG.16,ahigh-^ 

with the principles of the invention Is shown. Packet server 605 is a stored-program-control based processor archrtec- 
S. and P .nc.udes processor 650. memory 660 (for storing program instructions and data, e.g l J2S5S22u 
accordance with the above-mentioned GTP header compression, etc.) and commun.cat.ons .nterface(s) 665 for cou 
pling to one or more packet communication facilities as represented by path 666 

Lfl] The foregoing merely illustrates the principles of the invention and it will thus be appreciated that 1£m iMUed 
nttTe art will be able to devise numerous alternative arrangements which, although not explK5.tr/ descrtoed herem 
IbXthe principles of the invention and are within its scope. For example, although illustrated in the context of 
U^S thelnventl^e concept is applicable to any wireless system (e.g., UMTS, etc.) or application that reou.res use 
of a tunneling protocol. 
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Claims 

1 . A method for use In a packet server, the method comprising the steps of: 

40 negotiating compression of a GTP/UDP/IP header of a General Packet Radio Service based Tunneling Pro- 

toS (GTP) with a GTP peer, the GTP/UDP/IP header comprising GTP, User Datagram Protocol (UDP), and 
Internet Protocol (IP) header information; 

initially transmitting the GTP/UDP/IP header to the GTP peer; and 

subsequently transmitting a compressed version of the GTP/UDP/IP header to the GTP peer. 

45 2. The method of claim 1 wherein the compressed GTP/UDP/IP header comprises at least a tunnel identifier field 
that is less than or equal to four bytes in length. 

3. The method of claim 1 wherein the compressed GTP/UDP/IP header comprises at least, a " e *^ 
50 whteLdicateswhemeranextensionfieldisp 

a tunnel identifier field is present or not. 

4. The method of claim 1 further comprising the steps of: 

formatting data packets in accordance a Real Time Protocol (RIP) also having UDP and IP header information; 

compressing the RTP/UDP/iP header before transmitting the packets wherein one field of the compressed 
RTP/UDP/IP header defines whether a UDP checksum field is present or not. 
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